home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19960209-19960425 / 000360_news@columbia.edu _Mon Apr 8 19:08:38 1996.msg < prev    next >
Internet Message Format  |  2020-01-01  |  2KB
  1. Return-Path: news@columbia.edu
  2. Received: from apakabar.cc.columbia.edu (apakabar.cc.columbia.edu [128.59.35.159]) by watsun.cc.columbia.edu (8.7.3/8.7.3) with ESMTP id TAA11669 for <kermit.misc@watsun>; Mon, 8 Apr 1996 19:08:37 -0400 (EDT)
  3. Received: (from news@localhost) by apakabar.cc.columbia.edu (8.7.3/8.7.3) id TAA21807 for kermit.misc@watsun; Mon, 8 Apr 1996 19:08:34 -0400 (EDT)
  4. Path: news.columbia.edu!sol.ctr.columbia.edu!hamblin.math.byu.edu!acs2.byu.edu!news.cuny.edu!caen!spool.mu.edu!munnari.OZ.AU!news.ecn.uoknor.edu!news.ysu.edu!usenet.ins.cwru.edu!agate!dog.ee.lbl.gov!news.cs.utah.edu!cc.usu.edu!jrd
  5. From: jrd@cc.usu.edu (Joe Doupnik)
  6. Newsgroups: comp.protocols.kermit.misc
  7. Subject: Re: MSKermit 3.14 and WfW 3.11-Term Emul Probs
  8. Message-ID: <1996Apr8.092428.77838@cc.usu.edu>
  9. Date: 8 Apr 96 09:24:28 MDT
  10. References: <96092.192152U54294@uicvm.uic.edu>
  11. Organization: Utah State University
  12. Lines: 22
  13.  
  14. In article <96092.192152U54294@uicvm.uic.edu>, <U54294@uicvm.uic.edu> writes:
  15. > Hi all-
  16. >    I'm using 3.14 under WfW3.11 out of your average COM2 to a unix host
  17. > through a terminal server and ethernet. The hardware's a 386/SX-40 with
  18. > an 8250 UART. Under WfW, terminal emulation sessions invariably hang
  19. > and/or lose characters. I've tried everything suggested in the BWR file
  20. > that seems to fit (lock application in memory, increase priority, increase
  21. > memory available, removed SMARTDRIVE, lower speed), but no relief. The very
  22. > same hardware, settings, connections, user, etc., works just fine straight
  23. > from DOS, but start Kermit from Windows and I have problems.
  24. >    What's the magic bullet?...Thanks...Nick G.
  25. -------------
  26.     It's fairly clear that Windows is the culprit in this story. You
  27. can try other Windows serial port drivers (see the Windows NEWS groups for
  28. advice on those available), a better UART, watch carefully what's run in
  29. Windows that may eat cpu time (print spooling, for example, and clocks),
  30. and so on. In addition, you may have to investigate how your terminal server
  31. deals with flow control and match it on the desktop.
  32.     Kermit is seeing the serial port through Windows' emulation of it,
  33. and Windows is about as hostile an environment for communications as they
  34. come these days. Sigh.
  35.     Joe D.